BÁNH BÔNG LAN KIM SA PHO-MAI
Món ăn hot hit suốt mấy hôm nay đây ạ :D
Theo mình thì đây là món bánh hợp với người Việt cả về hương vị lẫn hình thức. Bạt bánh xốp mềm, lớp nhân kim sa trứng muối bùi béo, sốt phomai nướng xém mặt thơm ngậy, thêm chút vị mằn mặn của chà bông và rong biển. Nói chung nếu bạn đã từng mê mẩn bánh bao kim sa, bông lan trứng muối, hay bất kì loại bánh nào có trứng muối thì chắc chắn cũng sẽ “phải lòng” bạn này 😉
Cách làm rất đơn giản (tuy hơi nhiều công đoạn) nhưng thành phẩm lại cực kì cực kì xứng đáng, must try nhé cả nhà 😁😁
Danh mục nguyên liệu và các LƯU Ý QUAN TRỌNG khi làm có ở blog SD rùi nha: http://www.savourydays.com/cach-lam-banh-bong-lan-kim-sa-pho-mai/
sa sd 在 Re: [請益] 有公司用這種開發方式嗎? - 看板Soft_Job 的八卦
※ 引述《oaz (幸福治安：破案數/十萬人)》之銘言：
: ※ 引述《sniffer (again)》之銘言：
: : 永遠都會有沒考慮到的問題, 不然瀑布架構不會被檢討,
: 基本上，台灣的規格書是比較接近需求搜集，然後下一步就要實作
: 譬如：
: 規格書定義：一個畫面有三個按鈕，按了第一個要做什麼，第二個要做什麼事，第三個要做什麼事
: 但比較學院派的人作法，是比較接近物件導向分析與設計
: 譬如，會從使用者案例開始玩起
: 就使者案例來說，除此需求之外
: 還要考慮，使用者按了第一個按鈕後，再按第二個按鈕，這時候會如何？
: 或者，使用者連續第一個按鈕，會不會出什麼問題？
: 或者，這時系統發生了什麼事件，譬如網路斷線、東下下載完了
: 程式是否要通知使用者或更新書面
: 每種用法都要清清楚楚的列出來。如果有些結果還不確定，就要再回去
: 如果做得好，不會等到程式實作差不多後才發現
: 如果使用者怎麼做，會有大問題，所以要改架構
: 如果系統這時網路斷線，會有大問題，所以要改架構
: 做完使用者案例，還要做系統架構分析、物件分析
: 要達成每個案例，系統該包含哪些物件，有什麼責任
: 再根據每個物件
: 理論上，這都是 SA 、SD 的人要做的
: 但是，台灣只有 PM 提出要做什麼（還很不明確），
: 然後 RD 要身兼 SD、SD、PG
: : Boss, HW bug, OS bug 都會引起各種架構變化,
: 基本上，每種因素都會引起各種架構變化
: 因此：
: 一、當設計的時侯要儘量有彈性，這也是 SA、SD 要有足夠能力
現實中的程式, 必須要顧慮效能, 也要顧慮時效性,
最好效能的架構不會有彈性, 最快寫好的程式(例如perl)也往往最難維護,
但是最好維護從來都不是大多數程式的第一優先, 也不應該是優先:
1. 效能好的程式節能減碳, 這對server, driver或embedded system這類程式非常重要,
因為這些程式擁有最多的執行時間, 少用一個clock就少砍很多樹, 電池多活很久
2. 如果facebook慢慢做系統分析, 慢慢研究使用者行為, 慢慢推敲架構會不會DoS,
那他就不會成功, 先做出來才是重點
: 二、就風險管理的角度，儘管有一百種各式各樣的因素導致架構變化
: SA、SD 還是要能儘管可能掌控各種因素，譬如其中的九十種
: SA、SD 不能因為還有十種因素不能掌控，所以連那九十種因素都不掌控
: : 而且這樣做, 規格書可能比程式還多, SA自己寫全部code還比較快
: 照比較正規的作法（學院派），可能規格書真的比較 code 多
: 不過要考慮一個因素，是因為這種規格書比較因素比較多，所以才會比較厚
: 至於所謂的 SA自己寫全部code還比較快
: 基本上，這純粹是規模問題：
: 譬如要蓋一間狗屋，應該不會有人大材小用還給出一個規格書
: 當然是先動手做再說
: 但如果要蓋一棟高樓大廈，
: 總不會說規格書會太厚
: 設計師自己去蓋房子說不定還比較快
蓋房子設計師無法自己搬一棟樓的磚, 但是規格書裡面的流程假如比code還多,
SA直接用這個時間自己寫, 都已經做好了
一個很"正規"的例子, 世界前三大某IC豬屎屋, 他們的SDK就是在印度寫,
採用"正規"作法, 裡面每個模組都帶有比code還多的規格書, 測試報告,
其實這個產品全部的code只有幾MB, 但是拆成一百多個模組,
於是當我要修改電路板某個clock, 問他們的人會影響哪裡,
這件事情沒有人能告訴我, 所有的programmer都沒有辦法知道整個架構,
一點小小地修改都要找一群人開會, 大約要等二周,
或者自己看海量的文件, 找出所有用到這個clock的模組
文件比code還多的時候, 所謂的好維護根本只是為了以後可以告訴你,
他文件"有"寫到, 在編號E1046875r467文件的677頁120行....
找文件不會比找code方便, code至少是100%文字檔, C也比英文有結構
: : 每個函式都要定出來, 是用在程式模組之間的介面,
: : 不是要SA把程式架構裡的每個函式都弄出來,
: : programmer越高段, 模組就可以越粗略, 自行發揮就好,
: : 無法自行發揮的, 回去賣雞排啦
: : 無法理解程式運作的人, 同時也等於無法debug的人,
: : 能分工寫出來卻不能debug, 這算什麼分工
: : 君不見園區各大公司裡面, 往往只有幾個人負責設計,
: : 只是他們職稱都很大, 一般人以為他們沒做事而已, 他們累死了,
: : 如果還要他們寫架構書, 再去讓英文很爛的咖啡工程師把英文轉成程式,
: : 只會更沒效率, 更多咖啡工程師抱怨賣肝
: 所以說，是台灣不重視 SA 、 SD
: 否則，為什麼只有幾個人負責設計？
: 只有幾個 SA 、SD ，然後有幾百個 PG 嗎？
: 那是因為，在台灣， RD 要身兼 SA、SD、PG
: 如果是原作者說的那種玩法
: 那就要有數十位以至數百位 SA、SD，是公司最重要的資產
: 然後 PG 找工讀生或外包
這樣的架構, 一旦要改bug, 換規格, 反應非常慢, 大家時間都花在溝通,
programmer本來就應該有能力自己規劃模組的實踐, 自己為自己的程式負責,
而不是中間分出一大堆所謂SA/SD來, 架構的人沒在寫程式, 也沒有run程式,
寫的人只知道自己的一堆超簡單code block, 卻要找出整個程式哪裡掛了
: : 改規格是一定的, 如果需求都不會改變, 什麼都作成ASIC就好,
: : 哪裡需要軟體業, 軟體業就是為了"改"而生的, 全世界都一樣
: 改規格是一定的，但是 SA 、SD 要儘可能分析各種可能
: 儘可能設計到有彈性，使得之後的改變最小化
: SA、SD 不能因為還有十種因素不能掌控，所以連剩下的九十種因素都不掌控
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 112.105.197.233
... <看更多>